User Profile

 first would be to implement flow control on your reads and writes We already have a circular queue with limited capacity to maintain the outbound packets read from NE. We do not have much while writing inbound packets back to the NE because we are able to write to NE without any problems. We do not buffer or drop packets. Instead we write it to NE as soon as we receive it. I would expect NE to maintain a queue or similar mechanism when receiving inbound packets. Or would you suggest to manage inbound packets differently? Also, the problem here is that NE is retaining the packets passed to it. I do not see any packets persisting in my code. Only the NSData and NSArray I write to NE are persistent. Next, instead of using an @autoreleasepool, you could test using a dispatch queue with the autorelease frequency of DISPATCH_AUTORELEASE_FREQUENCY_WORK_ITEM to see if that makes a difference.  Wouldn't that be same as having an @autoreleasepool inside a block scheduled on a different queue? What I have right now is this: objc(size_t)writePackets:(const void*)buffer type:(uint32_t)type bufSize:(size_t)bufSize {     @autoreleasepool { NSData *pckts = [NSData dataWithBytes:buffer length:bufSize];     NSArray *protocols = [NSArray arrayWithObjects:[NSNumber numberWithUnsignedInteger:type], nil];         [self.packetFlow writePackets:@[pckts] withProtocols:protocols];     };     return bufSize; } What you are suggesting would result into something like this: objc(size_t)writePackets:(const void*)buffer type:(uint32_t)type bufSize:(size_t)bufSize {     dispatch_async(self.writeBackQueue, ^{         @autoreleasepool {/*This pool is added just for illustration purposes. It will be added implicitly by the queue attrs*/             NSData *pckts = [NSData dataWithBytes:buffer length:bufSize];     NSArray *protocols = [NSArray arrayWithObjects:[NSNumber numberWithUnsignedInteger:type], nil];         [self.packetFlow writePackets:@[pckts] withProtocols:protocols];         };     });     return bufSize; } I don't see why the @autoreleasepool in second would be better than first one. Few hints here would be helpful for me to understand.

My previous thought was that if you can trigger this crash by just reading these packet and not doing anything with them, this is absolutely a bug. Ok, let me try that out. Are you experiencing a memory bottleneck here though that you need to use @autoreleasepool? Yes, if we don't wrap writePackets call in @autoreleasepool, then memory usage keeps on increasing and hits the limit in few minutes. We also checked whether we have any leaks in our code causing this but instruments doesn't point any. So far only @autoreleasepool has been able to keep the memory usage in check.

If I may add, I am not in the favour of using @autoreleasepool around writing packets. But without that, the NSData and NSArray objects I create for writing packets and protocols, never get released. They always appear in persistent memory in Instruments and keep on adding to memory usage. Usually I would expect these (local) objects to be autoreleased in ARC. I noticed another developer reported having similar issue - https://developer.apple.com/forums/thread/665890?answerId=645942022#645942022 4 months back. Many other threads I have found on similar issue and all of them suggest to use @autoreleasepool. But shouldn't NetworkExtension release those objects once consumed. Or do we have any better way of handling this? Because I suspect @autoreleasepool is sometimes causing random crashes which are not in my code.

Another interesting data point would be if you can make this happen by just reading packets from the interface only. I am not sure what do you mean by that? Is there any other class I can read packets from in packet tunnel? Can you elaborate a bit more on how can I do that? One more thing I would like to add, not sure if related, is that we have an @autoreleasepool wrapping the code that writes packets back to the tunnelProvider.packetFlow. Could that be the cause of it?

Thanks for confirming eskimo. I have submitted a feedback: ********